👍🏻 definitely a good starting-point, good architecture, and what I've seen it shouldn't allocate too much* 😃

Review comments got a bit longer, though / sorry.

.editorconfig should be added and these rules run through code cleanup (end of file line endings).

So I expect this is the most performant solution we can use, should go forward with it -- here I'm pretty confident 🚀

What I don't like, and at the moment I have no better solution, is that the HttpUserAgentParser needs to iterate and test (~ brute force). But this is simple and clean code which together with the CachedHttpUserAgentParserProvider shouldn't be executed that often, as the majority of UAs should be served from the cache.

* when used with the cache it should be allocation-free (iif cache-hit), that's something I like very much!

The rest of this comment are some thoughts, but these won't hinder any progress of this PR.

How will the data in HttpUserAgentStatics be updated / kept up-to-date?
I have no knowledge on how often UAs change or new bots come into play. But maybe we should have some sort of generator that creates the entries for us. Or we load at runtime (maybe periodically) UA strings and add them to the dictionary/list/array.

You know I love metrics and counters, so (in the future) we should add some counters for cache hit / miss and write the raw UA strings as events. So we can gather data for AI and analyze it.
So we could also detect new bots, etc. by an alert from AI and update the list of kwown UAs.

.editorconfig for consistent newlines would be nice 😉

Modulo these points - LGTM.
You can bring the change in (once these are addressed).
Some other points (regex compiled, dictionary) we can address later, as it's no stopper for this PR / project.

Wow, I'm pedantic (sorry...).

I'd bring the benchmarks in as separate change.
A PR more won't harm the project, and the changes are separated cleaner.
We also have some follow up work to do.
Otherwise we have monster PRs with lots of comments and orthogonal change-sets.